IBIS Macromodel Task Group Meeting date: 28 April 2020 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis * Jared James Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan * Todd Bermensolo Stephen Slater Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Fangyi to send the updated DQ DQS clock forwarding draft to Randy to be submitted to the Open Forum as a BIRD. - Done. Submitted as BIRD204 and introduced at the last Open Forum meeting. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the April 21 meeting. Walter moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: BIRD201 - Addressing Radek's comments: Radek noted questions he had raised at the Open Forum meeting in advance of the scheduled vote (which was cancelled). He said he thought the interface between statistical and time-domain based training needed to be more precisely defined. He said we need to carefully define how "Dual" mode models should work and what the EDA tool is supposed to do. He noted that the Open Forum had agreed to send the BIRD back to ATM for discussion. He said Walter had sent out a quick update and clarification after the Open Forum meeting, but he thought it wasn't quite ready yet. Radek said he wasn't prepared to discuss it further at this meeting. Arpad asked if it was a technical change or just a clarification that was required? Radek said it was technical. Arpad asked if the intent was to change behavior? Radek said the intent wasn't really clearly spelled out in the current BIRD. Walter noted that he had a clear intent for how Dual mode models should work. He asked Radek to send him suggested changes. Radek took an AR to email Walter proposed changes. Bob noted several editorial issues: "support" -> "supports" and use of undefined "Init" in the BCI_training_mode row in the usage table. Walter said "Init" should be replaced with "Impulse". Radek and Walter asked that we defer further discussion and gather feedback and changes via email. Gap in IBIS for sampling with statistical mode AMI Models: Hansel shared a new presentation about a new BIRD draft. slide 3: - Statistical mode is used a lot. - Currently no means for the Rx AMI model to share precursor, cursor, postcursor locations with the EDA tool. - Larger question: Who controls calculation and presentation of the eye? - Shouldn't we give model makers as much control as possible? Arpad suggested that we have a similar issue with the GetWave() flow because returning clock ticks is optional. He said that if a model does not return clock ticks, then the EDA tool is left to formulate the eye. Hansel agreed. Arpad said one easy solution in the GetWave() flow might be to make returning clock ticks required. slide 4: Problem statement - AMI_Init() in IBIS 7.0 provides no way for the model to share the sampling point location with the tool. - We need a way to specify the cursor location, and we can then assume a 1 UI offset to the pre and post cursors. slide 5: Proposal - Introduce a new Reserved parameter Rx_Decision_Time - Usage Out, Type Float - Model outputs a time value in seconds that is the receiver decision point. - The time is with respect to time zero of the IR returned by the model. - Call it the "mean" or "median" sampling point. - If omitted, the EDA tool must determine the receiver decision point itself. Hansel noted that the model maker only has the IR to work with. He said that since the model maker can't return the distribution of jitter, the decision point must be considered the "mean" or "median" sampling point. Along the lines of his earlier comment about clock ticks in the GetWave() flow, Arpad suggested we might want to make this a required parameter. He also suggested that the statement in Usage Rules: "If omitted, the EDA tool will have to determine the receiver decision point on its own." might be venturing too far into specifying what the EDA tool should do. slide 6: Demo - Illustrative example - RX AMI model with CTLE, FFE, DFE - Model communicates via AMI_Init() call and returns Rx_Decision_Time. - This is essentially the cursor position relative to t=0. - Describes the position of the cursor, and by inference the pre and post cursors. slide 7: Time domain generation of pulse and step responses from an impulse response. - Illustration/explanation for model and tool developers - Conversion of impulse response to pulse or step responses. - Share some insight into the process. Probably won't be part of the specification, but perhaps part of the background information for the BIRD. - Important because IBIS doesn't define pulse and step responses. - Cursor positions are always defined with respect to a pulse or step response. - Impulse response contains no information related to unit interval. Michael noted that the unit interval is provided to the model in the bit_time argument to AMI_Init(). He said that the unit interval could only be inferred directly from a waveform input if the unfiltered pulse waveform itself were available. Ambrish asked if the BIRD might include a few generic steps on how to generate the value of this new Rx_Decision_Time, as an aid to both model makers and tool vendors. Hansel said he was open to this idea. Walter said the question was whether that should be in the BIRD itself (supporting details) or in a separate document. Walter said he didn't object to the idea in general, but he wasn't sure it was necessary. Fangyi said he agreed with Walter and Arpad that we don't necessarily want to prescribe what the EDA tool should do. Ambrish said he was only looking for guidelines on how the value is used. If the EDA tool has to know how to apply the value, then tool vendors have to know how the model derived it. Walter said that some standard things that a tool does, such as generating a pulse response from an impulse response, might just be left as expected knowledge in the industry. Arpad said we could revisit this question when we review the BIRD itself. slide 8: Summary of some questions/feedback/suggestions. slide 9: What is the symbol time/bit time used for PAM4? - Question from Michael - Refers to the "...bit time/symbol time..." statement in the Definition of the Issue section. - Is "symbol time" actually used, so PAM4 is supported? Walter noted that symbol time and bit time are the same thing for NRZ. He said it was a poor choice to name the argument bit_time, and that symbol interval would have been better. Walter/Fangyi/Michael/Arpad noted that IBIS 7.0 states that symbol time is placed in the bit_time argument for PAM4. So, the group agreed that EDA tools will provide the proper symbol time for this BIRD and PAM4 is supported. Michael noted that the PAM4 symbol time being passed in bit_time is explained on pages 203 and 208 of IBIS 7.0. Ambrish suggested this proposal's text should only refer to symbol time. slide 10: Should we use a different name for the new parameter? No one objected to the name. Ambrish said he thought it was good. slide 11: Should we also allow specification of the value as a fractional UI? - Question from Michael - Should Type UI be allowed as well as Float? (question from Michael) Hansel wondered if a fractional UI specified relative to a time 0 would be readily understood by model makers. Arpad noted that Vladimir had preferred absolute time, but that it's not hard to convert from one to the other. Michael said he had asked because he wondered, if something were a fixed fraction of the UI (i.e., it changes with the UI), if this would make it easier to specify. Radek said he saw no issue with supporting both, as they are interchangeable. The group agreed. slide 12: Do we call it mean or median sample point? Walter suggest that "ideal" might be a better term, since we are talking about the point where we want to make a decision, but the actual decision time will move with impairments like Dj, Rj, etc. Fangyi agreed that from a tool's perspective the model returns a sampling time and all the jitter is relative to that. Radek said he thought mean and median were confusing, and he suggested using Walter's proposed "ideal". Walter said "ideal" implies that you'll be adding jitter to it. Arpad noted the importance of the language "returned by the model" in: "... with respect to time zero of the impulse response returned by the model." He said he often sees cases where the IR returned by AMI_Init() is shifted relative to the input IR, and this language makes it crystal clear where the Rx_Decision_Time is applied. Hansel credited Ambrish with suggesting this language. slide 13: Clarifying the description of Rx_Decision_Time Hansel again noted Ambrish's "returned by the model" language and said this leaves the ball in the model developer's court. If the model maker does anything to introduce extra delay, for example, this has to be reflected in the output value of Rx_Decision_Time. Michael said his suggestion had been to adjust the text for clarity. He said the definition refers to "decision point", which in previous usages in IBIS has always referred to a physical location. However, here we are talking about a point in time. So, does it refer to delay from t=0 to the logic transition? We have to specify what the delay is between. Arpad said this could open a can of worms because the Rx could have a +-sensitivity range and then you'd be into questions of the edge rate and hysteresis. Walter suggested Hansel add Ambrish's question about whether to provide guidance on generation of pulse and step responses as an additional slide for next time. He also suggested Arpad's question about requiring clock ticks or making Rx_Decision_Time mandatory be added as a slide for next time. - Walter: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Radek to send suggested BIRD201 clarification language to Walter. ------------- Next meeting: 05 May 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives